NASA/TM-1999-206588
Automated Testing Experience of the Linear Aerospike SR-71 Experiment (LASRE) Controller
Richard R. Larson NASA Dryden Flight Research Center Edwards, California
September 1999
The NASA STI Program Office . . . in Profile
Since its founding, NASA has been dedicated to the advancement of aeronautics and space science. The NASA Scientific and Technical Information (STI) Program Office plays a key part in helping NASA maintain this important role. The NASA STI Program Office is operated by Langley Research Center, the lead center for NASA’s scientific and technical information. The NASA STI Program Office provides access to the NASA STI Database, the largest collection of aeronautical and space science STI in the world. The Program Office is also NASA’s institutional mechanism for disseminating the results of its research and development activities. These results are published by NASA in the NASA STI Report Series, which includes the following report types: • TECHNICAL PUBLICATION. Reports of completed research or a major significant phase of research that present the results of NASA programs and include extensive data or theoretical analysis. Includes compilations of significant scientific and technical data and information deemed to be of continuing reference value. NASA’s counterpart of peer-reviewed formal professional papers but has less stringent limitations on manuscript length and extent of graphic presentations. TECHNICAL MEMORANDUM. Scientific and technical findings that are preliminary or of specialized interest, e.g., quick release reports, working papers, and bibliographies that contain minimal annotation. Does not contain extensive analysis. CONTRACTOR REPORT. Scientific and technical findings by NASA-sponsored contractors and grantees. • CONFERENCE PUBLICATION. Collected papers from scientific and technical conferences, symposia, seminars, or other meetings sponsored or cosponsored by NASA. SPECIAL PUBLICATION. Scientific, technical, or historical information from NASA programs, projects, and mission, often concerned with subjects having substantial public interest. TECHNICAL TRANSLATION. Englishlanguage translations of foreign scientific and technical material pertinent to NASA’s mission.
•
•
Specialized services that complement the STI Program Office’s diverse offerings include creating custom thesauri, building customized databases, organizing and publishing research results . . . even providing videos. For more information about the NASA STI Program Office, see the following: • Access the NASA STI Program Home Page at http://www.sti.nasa.gov E-mail your question via the Internet to help@sti.nasa.gov Fax your question to the NASA Access Help Desk at (301) 621-0134 Telephone the NASA Access Help Desk at (301) 621-0390
•
•
•
•
•
• Write to: NASA Access Help Desk NASA Center for AeroSpace Information 7121 Standard Drive Hanover, MD 21076-1320
NASA/TM-1999-206588
Automated Testing Experience of the Linear Aerospike SR-71 Experiment (LASRE) Controller
Richard R. Larson NASA Dryden Flight Research Center Edwards, California
National Aeronautics and Space Administration Dryden Flight Research Center Edwards, California 93523-0273
September 1999
NOTICE
Use of trade names or names of manufacturers in this document does not constitute an official endorsement of such products or manufacturers, either expressed or implied, by the National Aeronautics and Space Administration.
Available from the following: NASA Center for AeroSpace Information (CASI) 7121 Standard Drive Hanover, MD 21076-1320 (301) 621-0390 National Technical Information Service (NTIS) 5285 Port Royal Road Springfield, VA 22161-2171 (703) 487-4650
Automated Testing Experience of the Linear Aerospike SR-71 Experiment (LASRE) Controller
Richard R. Larson NASA Dryden Flight Research Center Edwards, California Abstract System controllers must be fail-safe, low cost, flexible to software changes, able to output health and status words, and permit rapid retest qualification. The system controller designed and tested for the aerospike engine program was an attempt to meet these requirements. This paper describes (1) the aerospike controller design, (2) the automated simulation testing techniques, and (3) the real time monitoring data visualization structure. Controller cost was minimized by design of a single-string system that used an off-the-shelf 486 central processing unit (CPU). A linked-list architecture, with states (nodes) defined in a userfriendly state table, accomplished software changes to the controller. Proven to be fail-safe, this system reported the abort cause and automatically reverted to a safe condition for any first failure. A real time simulation and test system automated the software checkout and retest requirements. A program requirement to decode all abort causes in real time during all ground and flight tests assured the safety of flight decisions and the proper execution of mission rules. The design also included health and status words, and provided a real time analysis interpretation for all health and status data. Nomenclature ACTS ARM/H2 AS ASC ASSC CCP CIMS CO cp CPDF CPU FDAS GH2 GHe aerospike controller test system dual button on control panel to first, arm autosafe modes and second, dump hydrogen autosafe state allied signal controller aerospike system controller cockpit control panel calibration information management system cutoff state cockpit panel simulator page control program data file central processing unit flight data access system gaseous hydrogen gaseous helium
He H2 H2O ID I/O imxtst LASRE LO2 logc MAH MAS MCC mdl OFP PCM prst psia RLV RTF setredline SMART SS TEA-TEB TRAPS TM V and V val VME waitst Introduction
helium gas hydrogen gas water, and label for control panel button to dump water identification input/output time out parameter, ms Linear Aerospike SR-71 Experiment liquid oxygen, and label for control panel button to dump liquid oxygen log clear command master abort hold state master abort sequence state mission control center model simulation page operational flight program pulse code modulator power reset pounds per square inch, absolute reusable launch vehicle real time FORTRAN abort limit value signal management for analysis in real time start state triethylaluminum-triethylboron telemetry and radar acquisition processing system telemetry verification and validation value simulation page Versa Module Eurocard wait state
Efforts in the space industry are being made to reduce the cost of placing payloads into orbit. One proposed design is a single-stage-to-orbit approach, which utilizes a rocket-powered reusable launch vehicle (RLV). For this concept to be feasible, a more efficient propulsion system must be explored. One such system is the linear aerospike engine, which was first developed in the 1960’s.1–3 As a flight demonstrator Lockheed Martin is developing the X-33 program to validate the feasibility of the RLV
concepts and the aerospike engine. To support this program the Linear Aerospike SR-71 Experiment (LASRE) 4 was initiated to obtain flight test data on this unique engine design. An SR-71 aircraft was modified to carry the aerospike engine and its feed systems. These modifications were mounted at the rear of the aircraft between the ventrals as shown in figure 1. The Linear Aerospike SR-71 Experiment (LASRE) engine supply systems were enclosed in a pod consisting of hydrogen (H2) for the fuel, liquid oxygen (LO2) for the oxidizer, water (H2O) for engine cooling, triethylaluminum-triethylboron (TEA-TEB) for the igniter and helium (He) for purging and tank pressurization (fig 2). Control and monitoring of these systems was accomplished using a single channel, aerospike system controller (ASSC). The basic function of the ASSC is operation of solenoid valves that control the LASRE engine supply systems. A subset of the valve layout is shown in figure 3. The ASSC manipulation of these valves produces a firing-flow sequence as shown in figure 4. The start-states (SS) sequence begins with purges of helium (He) in the LO2 and TEA-TEB lines. A liquid oxygen trickle flow is then commanded to prechill the line, which is followed by an initial water-trickle flow to fill the passages in the engine. The main water and liquid oxygen flow starts and then the TEA-TEB igniter begins. The hydrogen line is purged briefly to prevent backflow and finally, the valve is opened. At this point the engine firing begins and lasts for 3 sec. The cutoff (CO) states begin when the hydrogen and liquid oxygen valves are closed. The water flow stops, and then purges begin to prevent backflow. The autosafe (AS) modes would be initiated next to complete water, liquid oxygen, and hydrogen purges. The LASRE program was conceived with an aggressive schedule to obtain flight data at minimum cost. Design considerations for the ASSC were low-cost, man-rated, reliable, fail-safe, with easy to change software, and rapid verification and validation (V and V) capabilities of software. Any first failure needed to be immediately detected by the system and followed by an automatic abort to a safe configuration. Testing configurations and anomalies frequently required changes to the ASSC software. Software modifications had to be quickly and thoroughly tested to meet schedule constraints. Any aborts needed to be identified in real time for safety of flight decisions and be quickly debugged. These challenging requirements led to the three main parts of this paper. First, a description of the ASSC fail-safe, single-string, design; second, the automated V and V software testing; and third, the real time, intelligent monitoring system used for LASRE system tests. Use of trade names or names of manufacturers in this document does not constitute an official endorsement of such products or manufacturers, either expressed or implied, by the National Aeronautics and Space Administration. LASRE Control System The LASRE controller architecture is comprised of four primary components (fig 5). These are the ASSC, the allied signal controller (ASC), the pulse code modulator (PCM) data instrumentation system, and the cockpit control panel (CCP). The solenoid valves are controlled from the ASSC, which receives system temperature and pressure data from the PCM instrumentation system and operator commands from the CCP. Command of the main control valves for the water, liquid oxygen, and hydrogen feed systems is done from the ASC, which receives inputs from the ASSC. Health and status information is also passed from the controllers and telemetered (TM) to the ground. Figure 6 shows the LASRE cockpit control panel, which provides the operator with status lights and push buttons for mode control. The firing sequence starts by first pressing the PRESTART and then the START button. After the firing, the autosafe mode is armed by pressing the ARM/H2 button. From this mode any of the autosafe modes may be selected to dump the hydrogen, water, and liquid oxygen systems.
Aerospike system controller (ASSC) Software modules for the ASSC are shown in figure 7. The ASSC software consists of the operational flight program (OFP) and the control program data file (CPDF). A state table is merged with the calibration information management system (CIMS) data file to create an executable state table load file. The OFP normally does not need to be changed. These software modules will now be described in more detail. Operational flight program (OFP) The OFP manages all controller input/output (I/O) functions. It reads the experiment pressures and temperatures from the PCM data stream, the ASC status words, and switches from the CCP. Outputs include solenoid valve commands; main control valve motor clutch (or motor relay) commands; inputs to the ASC for operation of the hydrogen, liquid oxygen, and water valves; and CCP lights. The OFP begins execution at power up. At initialization the executable state table file is opened. Dynamic memory allocation is created for the states, transducers, and PCM variables. The decommutator card is initialized with data from the setup record and fixed data. Each record is read in the file and the data is passed through to the state in which it belongs. The watchdog, PCM, and ASC interrupts are initialized and monitored. Failure monitoring is performed from continuous self-tests:
• PCM mismatch wrap test • watchdog monitor • over-temperature abort (controller, main servoamps) • ASC word check (count, status) • main valve command and position mismatch
A PCM interrupt is issued every 2.5 ms as shown in the real time loop description in figure 8. In frame 0 the controller reads the input data and in frame 2 the controller compares a copy of the data from frame 0. If the comparison test fails, then a fail is declared for the PCM mismatch wrap test and the abort flag is set. There is a 1-frame persistence counter set for this and all other failures. State table The state table defines actions and redline/transition checks that the controller must follow to perform a test point instruction. It is written in a readable format to aid the user in modifying the instructions. The state table contains the following: version (identifier for the table), state declarations (functions for each state), and an end (end of table). Each state structure must contain a state name, a default state name, an actions list, and a transition function. A state table example for typical components is shown in figure 9. When this state is entered, the controller performs the actions listed and stays at this point until the timer reaches 2.0 sec, at which point the transition to SS1:30 is done. The state table commands for the actions and transition functions are shown in tables 1 and 2. These functions are used to control the LASRE systems as required for the test.
Control program data file (CPDF) The CPDF reads the CIMS data file and the state table. The CIMS file contains the calibrations for all the PCM signals. An executable program is created from these two files. The CPDF is written in C programming language and interprets the state table as a linked-list data structure. This is illustrated in figure 10. Generally at every state there are two pointer possibilities, (1) normal transition and (2) abort transition. Memory allocation is created for each state defined in the state table and for every transducer that is referenced including its calibration coefficients. Any number of state transition points may be easily added or deleted from the state table, thereby making this structure easy to build. Transducer records are created from the CIMS file by searching for frame word position, frame number, frame depth, data type, minimum count, maximum count, and scaling coefficients. The state table is read line-by-line with the appropriate records such as state, default, action, transition, and end. The CIMS data parameter values are converted from engineering units back to counts for the real time processing. Flow chart The states and the transitions flow is represented in figure 11 as a flow chart. With power-on the system starts at the initialization states and automatically transitions to a master standby state. The system waits at this mode until commanded to prestart or to the autosafe modes for a normal start path. From prestart the system may be commanded to start, which is then followed by an automatic transition to shutdown and then return back to a master standby mode. At each state there is an automatic abort path possible. The autosafe modes may be entered from master standby or master abort hold states as shown. Redlines Parameter redlines are used to set limits, either above or below specific signals, to test for abnormal conditions. This may be indicative of a stuck valve, failed sensor, leak, or plugged line. Signal redlines are set or cleared in any states, as desired. This allows for a flexible system. Table 3 shows the fault transitions, including redline values, for each state. Status words The controller status words are formatted on the PCM data stream for recording and monitoring. The state transition information is shown in table 4. These words provide information about the current state number, type of transition, redline values in effect, and abort causes. Additional abort information is contained in a word in which bits are defined in table 5. These words contain all controller abort information. Allied signal controller (ASC) The ASC receives commands from the ASSC for the main valves (GH2, LO2, and H2O). It then provides detailed control for these motor-operated valves, using position feedback for the LO2 and H2O valves to provide on/off ramping and pressure feedback for the GH2 valve for pressure regulation. The ASC also receives status requests from and provides health/status information to the ASSC. It is capable of shutting the main valves and stopping the test if it detects an error in the status requests from the ASSC. This feature provides a measure of control system abort redundancy.
Pulse code modulator (PCM) The PCM data instrumentation system collects and packages all LASRE data into frames, in a continuously cycling data stream, for telemetry to the ground. This includes experimental data, control system temperature and pressure data, and ASSC status information. The entire data stream is also provided to the ASSC, which uses control system pressures and temperatures. The timing of these data frames also provides external interrupts for the ASSC. Aerospike Controller Test System Description (ACTS) The ASSC software was modified and tested using a real time simulation. A simplified block diagram of the LASRE controller simulation is shown in figure 12. This test system allowed for closed-loop testing with the controller by driving all the necessary hardware interfaces. A 486 CPU was used to create an executable state table from a CIMS signal calibration file and a source state table file. This executable file was then downloaded into the ASSC for testing. As part of this simulation an Aerospike Controller Test System (ACTS)5 was designed to facilitate V and V testing of the ASSC. The ACTS allowed inputs to be controlled as a function of the state sequence so that the appropriate time intervals were maintained to allow the ASSC to proceed through the entire test sequence. In addition, simulated failure inputs were provided to verify that the controller would follow the proper abort sequences. Sensor model The experiment sensors consist of pressure values, temperature values, and an emergency shutdown switch voltage. These sensor values are output to the PCM data system through digital-to-analog converter boards in the Versa Module Eurocard (VME) card cage. Values are set for these sensors by the ACTS software that is based on the current state of the controller. This sensor model file is shown in table 6. As the state table begins execution sensor redlines are established according to the current state. The ACTS reads the controller states and sets the appropriate sensor values as defined in the table. Pulse control modulator data system The PCM data system reads the analog sensor values and generates a PCM bit stream for input to the ASSC. The PCM data system also inputs a serial data stream from the ASSC containing health and status information. The PCM bit stream is also sent to a PCM decommutator board in the VME card cage so that the ACTS program knows the controller state. Pulse control modulator decommutator board The PCM bit stream generated by the PCM data system includes the state of the controller. Since the ACTS program needs to know the controller state in order to set sensor values, this PCM bit stream must be read. Solenoid valves There are 19 solenoid valves that are controlled directly by the ASSC. Valve commands are input from the controller by way of an input discrete board in the VME card cage.
Allied signal controller (ASC) The ACTS program normally simulates the ASC. However, there is provision to substitute the flight hardware ASC in the simulation if desired. The interface for the ASC includes 4 discrete inputs to the test system through an input discrete board in the VME card cage. Three of the discrete inputs are used by the controller to operate three valves (LO2, GH2, and H2O). The remaining discrete is used to request status information. The ASSC status request discrete line is set high for approximately 2.5 ms to request status. The status request occurs at a 100 Hz rate. The ACTS program responds to the status request within approximately 5–7.5 ms, otherwise a fault bit is set. Cockpit control panel (CCP) The CCP signals are interfaced to the controller through output and input discrete boards in the VME card cage. A simple graphic display was generated to simulate the cockpit panel with the proper buttons, toggle switch, and colored lights. This graphic display was completely functional for the software tester. Aerospike controller test system software (ACTS) The ACTS program is written in FORTRAN and ANSI C. The user interface is the same as that used in the standard Dryden flight simulations. This includes a simple command line and display interface. The real time part consists of two main loops. The primary loop runs at 100 Hz and includes the cockpit panel input/output, valve/clutch monitoring, and data recording. The secondary loop runs at a much higher rate (~1000 Hz). This fast loop checks the status request line and the PCM bit stream and responds with the appropriate action. When the status request line goes high, status information is immediately sent to the aerospike controller through the serial port. When a new PCM minor frame is received, the controller state is checked as well as the subframe identification (ID). If the controller state has been changed, the appropriate sensor values are updated based on the state table. The subframe ID determines which set of values to output for the multiplexed temperatures. Manual ASSC testing The ACTS program was designed to set and monitor the I/O to the ASSC. Verification and validation testing was conducted by starting the ACTS program and then powering up the controller. Both the ACTS program and the controller powered up in the first state indicated by the state table. From that point, testing was conducted manually, if desired, by pressing the appropriate buttons on the cockpit panel to initiate and proceed through the test sequence. The ACTS program created a time-tagged, log file of the following items during the test: 1) Controller states 2) Transition status 3) Sensor value set (based on state change) 4) Valve/Clutch commanded open/close (on/off) 5) Cockpit buttons change position 6) Cockpit lights turn on/off
Automated ASSC Test Results The ACTS program was designed to read a command file that would control the same simulation inputs as were done manually. This structure allowed for a repeatable, fast, and time-controlled test sequence. An example of a script file is shown in table 7. This script sets the pressure signal (PT0001) to 325 psi when the ASSC is executing state number SS1:36. At this moment the state table is commanding a pressure range test as shown below. Setredline PT0001 outside 150 320 goto mas:1 Chamber Pr redline A timeout parameter (imxtst) and wait state (lwaitst) is set in the script in case the test fails. For this test a 60-sec wait time is set. If the state does not go to the MAH:1 within 60 sec, the following message is set. WARNING: Timed out waiting for state: MAH:001 If the signal is outside the range 150 to 320 psi, this test verifies that the setredline command for this pressure causes a transition to the specified abort state (mas:1). For this example only the upper limit of 320 only is tested. A portion of the resulting test log file that was generated for this script is shown in table 8. When state SS1:36 was entered, the signal PT0001 was set to 325 psi (exceeding the 320 psi limit). Other operations were performed as commanded for this state and finally a transition message (shown in bold type) was generated. This message was generated by reading the ASSC status words described in table 4. Words 1–6 identified the transition signal (PT0001), word 7 identified the code (O - outside), word 8 is not applicable for this cause, word 9 contains the upper limit checked (320 psi is 2078 PCM counts), word 10 has the current value (325 psi is 2110 PCM counts), and finally words 11–14 show the state which the transition occurred (SS1:36). Hundreds of similar scripts are written to automate the V and V process for the ASSC. These scripts may be combined in a single, autotest file and all run at once. An excerpt of an autotest file is shown below. # Run the script macro /home/not/acts/ST_HOTFIRE/VnV/Scripts/Start/start_as01.scr # Save the logfile logs /home/not/acts/ST_HOTFIRE/VnV/Logfiles/Start/start_as01.log # Run the script macro /home/not/acts/ST_HOTFIRE/VnV/Scripts/Start/start_as02.scr # Save the logfile logs /home/not/acts/ST_HOTFIRE/VnV/Logfiles/Start/start_as02.log # Run the script macro /home/not/acts/ST_HOTFIRE/VnV/Scripts/Start/start_as03.scr # Save the logfile logs /home/not/acts/ST_HOTFIRE/VnV/Logfiles/Start/start_as03.log
Script files were created to test every normal/abort state transition, all controller functions, all redline aborts, and all aborts caused by the ASSC and ASC monitors. Refer to figure 11 for the state transitions and table 3 for the fault transitions and redline conditions. The status words themselves described in tables 4 and 5 were tested for correct status. As a result of this software testing automation, an exhaustive set of test cases were quickly executed and easily analyzed. The time to qualify software changes to support LASRE testing was significantly shortened. Mission Control Center Real Time Monitoring Results Intelligent monitoring systems have been developed for flight programs such as the space shuttle to aid in identifying problems in real time.6 The LASRE program had a similar requirement to monitor and process the ASSC status words (tables 4 and 5) in real time so that any abort condition would be immediately known. Therefore, an automated, real time analysis tool was used to filter the status words based on events as textual strings and numerical values and output this information onto an X-window message stack. This tool was developed in-house at NASA Dryden and is called signal management for analysis in real time (SMART). The rule-based, intelligent real time monitor7 was used for all ground and flight tests in the mission control center (MCC). Real time FORTRAN (RTF) processing The PCM real time data processing is shown in a top-level data flow in figure 13. Signals are telemetered at their frame rate. This is 100hz for the ASSC. The data enters a receiver rack, which sends it out to a telemetry and radar acquisition processing system (TRAPS), and front-end processor. The data is converted into engineering units in a real time FORTRAN (RTF) processor at 100 Hz and then sent out on an Ethernet data server. This server sends the data to the Unix workstations in the MCC at about 15hz. Unfortunately, this is too slow to read the abort status words that exist for only 10 ms. In order to catch the abort status words, latching logic was programmed into the RTF as shown in figure 14. The ASSC status words are read at 100hz and if there are no aborts several previous states are saved in a ring buffer. When an abort flag is set, the ring buffer stops updating and a latch flag is set. These buffered signals contain the abort cause and are sent out through the Ethernet server to the SMART application. The SMART decodes these raw buffered words into messages defining the abort reason. When the abort flag is reset, the ring buffer begins updating the status words again and the latch flag is reset. SMART message stack The SMART monitor application was used in the MCC to display the LASRE abort codes. An example of the message stack is shown in figure 15. New messages are added to the stack at the top and the older messages are pushed down. As messages are cleared off the stack, the messages automatically compress, thus filling in the gap between messages. The example shown in the figure is from an ASSC abort. The cause was determined by reading the status words defined in table 4 from the latched ring buffer and converting this information to a message string. In this case the pressure signal (PT0651) exceeded a redline limit of 30 psi. The pressure at the time of the abort was 33 psi and the ASSC was in the state as 2:11. Other information about each of the main control valves is also shown. SMART log file The SMART message window also had an option to save all the messages that are both set and rescinded to a log file. Included in the SMART knowledge base were rules for the state messages.
After the test was completed, the SMART log file was saved and Unix commands were run to scan out the state messages. This was done to get a quick and rough estimate of which states were executed and their times. The flight data access system (FDAS) states and times had to be run the following day for exact states and times from a batch file. A comparison of the FDAS and SMART states is shown in table 9. The SMART missed some of the states because of the slow sample rate of the Ethernet server and the SMART architecture that writes to a file on the hard disk while still running in real time. The times were comparable, however, for a quick and gross check. This log of the state times proved invaluable for determining event times for batch data analysis and plotting. Conclusion The aerospike system controller (ASSC) had challenging requirements to be fail-safe, low cost, flexible to software changes, and a quick V and V software turnaround. These conditions were satisfied by using a clever architecture and through the use of auto-testing tools. The ASSC was fail safe because of the conservative approach in actively monitoring status, health, and sensor redlines. Any failure in the system would automatically transition to an orderly and safe shutdown sequence Using a simplex signal set from the pulse code modulator (PCM) rather than dedicated ASSC signals had never been done at NASA Dryden. This approach resulted in a significant cost reduction. Calibrations for PCM signals became an input file for the ASSC software. The operational flight program (OFP) interrupts were slaved to the PCM frames. The ASSC was single string, which also reduced the cost. Software changes were easy to make because of the link-list structure. States could easily be added, deleted, or modified in the state table file. The control program data file (CPDF) software made it easy to change the calibration information management system (CIMS) and state table input files to generate a new executable ASSC program. The aerospike controller test system simulation provided a test tool to automate the verification and validation runs. Exhaustive script files were run from a single master file to automatically test every path and abort. The log files provided an archive record of the test results. Status words from the ASSC provided excellent insight to ascertain the condition of the controller. These words contained states, abort codes, transitions, and input/output discretes. This data proved invaluable in providing information about the controller to debug and assess problems. Status words were automatically decoded in real time using the signal management for analysis in real time (SMART) application in the MCC during all testing of the LASRE. Immediate analysis of any controller problem was demonstrated and proved to be a great help in conducting the LASRE tests. In addition, the automated time-tagged states that were generated from SMART in real time during the testing were a tremendous help in identifying event times for further off line analysis. References
1
Angelino, Giafranco, “Approximate Method for Plug Nozzle Design,” AIAA Journal, vol 2, no. 10, Oct. 1975, pp. 1834-1835.
2
Rockwell International Corporation, “Advanced Aerodynamic Spike Configurations: Volume 2–Hot Firing Investigations,” AFRPL-TR-67-246, Sept. 1967. (Distribution authorized to U.S. Government agencies and their contractors; other requests shall be referred to WL/FIMS Wright-Patterson AFB, Ohio 45433–6503.)
3
Mueller, T. J. and W. P. Sule, “Basic Flow Characteristics of a Linear Aerospike Nozzle Segment,” ASME-72WA/Aero-2, Nov. 1972.
4
Corda, Stephen, Bradford A. Neal, Timothy R. Moes, Timothy H. Cox, Richard C. Monaghan, Leonard S. Voelker, Griffin P. Corpening, and Richard R. Larson, Flight Testing the Linear Aeropike SR-71 Experiment (LASRE), NASA TM-1998-206567, Sept 1998. Kellogg, Gary V., and Ken A. Norlin, “Aerospike Controller Test System,” NASA Tech Briefs, vol. 21 No.2, Feb 1997, pp.28–30.
6 5
Land, Sherry A., Jane T. Matlin, Carrol Thronesberry, Debra L. Schreckenghost, Making Intelligent Systems Team Players, A Guide to Developing Intelligent Monitoring Systems, NASA TM 104807, July 1995.
7
Larson, Richard, and D. Edward Millard, A Rule-Based System for Real-Time Analysis of Control Systems, NASA TM 104258, Oct 1992.
Table 1. State table actions functions. Function ON
OFF OPEN CLOSE RESET TIMER ACTIVATE DEACTIVATE SETDEF SETREDLINE ABOVE, BELOW, OUTSIDE goto SETREG CLEARREG SETPRES CLEARPRESS CLEARABORT Description Set cockpit control lights Command to open/close solenoid valves Reset state table timer Engage main valve clutches/relays Starts health monitoring of specified processor
The function transitions to the goto state when the pressure signal is outside the specified limits
The pressure is regulated from the upper limit to the lower limit by opening the specified valve Clears regulator function The pressure is regulated from the lower limit to the upper limit by opening the specified valve Clears pressure regulator function Resets any abort flags
Table 2. State table transition functions. Function TIMER wait